The present invention relates to computer security and, more particularly, to an efficient method of screening untrusted digital files.
Malware is software used or created by attackers to disrupt computer operation, gather sensitive information, or gain access to private computer systems. Malware typically is distributed by being embedded in innocent looking digital files. These files can be either executable files, such as object files and scripts, or nominally non-executable files, for example word processing documents.
One known method to test an untrusted digital file for the presence of embedded malware is to run the file in a secure virtual environment. In the present context, “running” a file means doing to the file what a user normally would do to use the file. In the case of a nominally executable file, “running” the file means executing the file. In the case of a nominally non-executable file, “running” the file means opening the file using the appropriate application. For example, “running” a Microsoft Word™ file means opening the file using Microsoft Word™ and “running” a .pdf file means opening the file using Adobe Acrobat™ or Adobe Acrobat Reader™. The secure virtual environment that is used for this purpose is commonly called a “sandbox”. A sandbox provides a tightly controlled set of resources, such as scratch space in a hard disk, for running untrusted digital files. Network access, the ability to inspect the host system and the ability to read from input devices is either disallowed or heavily restricted.
As an untrusted digital file is being run in a sandbox session, the sandbox code monitors the session for attempted malicious activity. Examples of such malicious activity include unexpected process creation, unexpected process termination, unexpected setting or deletion of registry entries, unexpected reading and/or writing of files, and unexpected network activity such as opening TCP/UDP; connections, HTTP requests and DNS queries. A file that runs without attempting anything malicious is considered trustworthy or benign. A file that attempts malicious activity is therefore known to have malicious code embedded therein. The usual way to monitor a session for attempted malicious activity is to log selected activity of the session and to inspect the log after the session for attempted malicious activity. The following table is an example of a small portion of one such log for a Microsoft Windows™ operating system:
ActivityTypePathOrigin ProcessActivityprocessC:\Windows\System32\services.exeC:\Windows\System32\sppsvc.execreatedfileC\Windows\System32\tmp.txtC:\Windows\System32\svchost.execreatedsystemregistryServices\TCPIP\Linkage\BindC:\WINDOWS\explorer.execreated
Conventionally, the untrusted digital file is allowed to run to completion, even after malicious activity has been detected, for two reasons. First, it is conventional wisdom that a system administrator should be given a complete report of attempted malicious activity. Second, a complete log provides clues to new malware patterns.
Conventionally, untrusted files are tested individually in this manner. The throughput of such testing of untrusted files can be improved by running several sandboxes simultaneously, but this may be expensive in terms of the system resources, especially memory, that need to be devoted to such testing.